1. Field of the Invention
The invention is in the field of computer graphics, and more particularly to interfacing computer graphics programs.
2. Description of the Prior Art
Typically, to get the greatest performance from a graphics processor, graphics programs are written in assembly code for a specific graphics processor. Using assembly code is highly restrictive because it does not allow for abstractions and optimizations. In particular, in assembly code, programmers must reference parameters associated with an image using actual hardware addresses of a memory location where a particular parameter is stored. For example, a parameter such as color must be referenced in assembly code with the actual hardware address of the memory location, such as a register number or name, where the color parameter is to be stored.
The hardware addressing of parameters at the assembly code level, referred to as absolute addressing, does not allow for hardware abstraction in the programming and creates two significant problems. First, it is difficult to change an assembly code program if a particular parameter needs to be stored in a different memory location because each hardware address of the memory location in the assembly code program must be changed. Second, it is difficult to use the assembly code program with other graphics processors because the parameters in the assembly code have been referenced by hardware addresses that are specific to the graphics processor it was originally written for. Therefore, the ability to “mix and match” an assembly code program with different graphics processors is limited in the prior art. In addition, assembly code programs are not self-explanatory and difficult to read because only hardware addresses are used to reference parameters instead of parameter identifiers, such as color or position.
These problems are magnified when a first assembly code program is interfaced to a second assembly code program where the first assembly code program outputs graphics data that is used by the second assembly code program. When interfacing the first assembly code program to the second assembly code program, the parameters output by the first assembly code program and the parameters input by the second assembly code program must first be ascertained to determine the compatibility of the first and second assembly code programs. To determine compatibility, the code of the first and second assembly code programs must be thoroughly examined to locate all hardware addresses, to determine the parameter referenced by each hardware address, and to determine any common parameters between the first and second assembly code programs. The first and second assembly code programs must then be modified so that the hardware addresses that reference common parameters match between the first and second assembly code programs. This allows the correct graphics data for each common parameter to be passed from the first assembly code program to the second assembly code program.
Therefore, the hardware addresses and parameters of the first and second assembly code programs must be known before compatibility can be determined. Also, extensive modifications of the first and second assembly code programs may need to be performed before they can be interfaced. Thus, the ability to interface or “mix and match” different assembly code programs is limited in the prior art.
Therefore, there is a need for a system and method for allowing hardware abstraction in the interfacing of graphics program modules to allow graphics program modules to be independent of the details of the hardware-level interface. This system and method should allow the graphics program modules to be independent of the actual hardware addresses of a particular graphics processor and thus allow greater “mixing and matching” ability between a graphics program module and various graphics processors. Also, this system and method should provide a fast and easy way to determine and provide compatibility between a first and second graphics program module to allow greater ability to interface or “mix and match” a graphics program module to other graphics program modules.